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I.  INTRODUCTION 

This  report  describes  SCHEDULER,  a  computer  program  developed  by 
Desmatics,  Inc.  as  an  aid  in  solving  a  particular  type  of  scheduling 
problem.  The  fact  that  SCHEDULER  is  implemented  on  a  computer  is  only 
significant  in  terms  of  the  speed  with  which  a  scheduling  run  can  be 
made.  The  use  of  a  computer  performs  no  special  magic  in  this  particular 
scheduling  application,  nor  in  any  other  for  that  matter.  The  computer 
program  is  only  a  formal  statement  of  an  algorithm  which  has  been  devised 
to  perform  a  task  in  compliance  with  a  set  of  rules.  The  algorithm  could 
just  as  well  be  accomplished  with  paper  and  pencil,  but  a  computer  does 
the  job  much  faster  and,  once  the  program  is  properly  tested  and  •debugged^, 
more  accurately. 

This  report  defines  the  type  of  problem  addressed  by  SCHEDULER, 
indicates  the  approach  employed  by  the  program  in  attacking  the  problem, 
lists  the  capabilities  and  limitations  of  the  program,  discusses  some  of 
the  runs  which  have  been  made  and  presents  the  conclusions  which  have  been 
drawn  from  these  runs.  The  report  also  suggests  some  further  developments 
which  would  enhance  the  program's  efficiency.  The  appendices  provide  a 


technical  description  and  a  flow  chart  of  the  program. 


A.  PROBLEM  \ 

There  exists  a  type  of  problem,  not  unlike  that  of  scheduling\the  work 
for  machines  in  a  job  shop,  which  confronts  experimenters  who  must  plan  the 


administration  of  research  studies  in  which  a  pool  of  subjects  is  assigned 
to  a  set  of  related  experiments  or  tests.  For  this  type  of  problem,  the 
task  is  to  determine  a  schedule  which  minimizes  the  span  of  time  over  which 
testing  takes  place,  while  satisfying  a  specified  set  of  constraints.  Thus, 
the  problem  is  to  provide  the  efficient  utilization  of  a  set  of  resources. 
Given  a  varying  group  of  subjects,  a  relatively  complicated  configuration 
of  resources  and  facilities,  and  a  large  number  of  interrelated  experiments 
to  be  conducted,  the  scheduling  problem  becomes  extremely  difficult  for  an 
experimenter  to  undertake  unaided. 

SCHEDULER  was  developed  as  an  aid  in  preparing  schedules  at  the  Naval 
Aerospace  Medical  Research  Laboratory  (NAMRL)  Detachment  for  human  subjects 
used  in  the  evaluation  of  a  large  number  of  candidate  performance  tests  as 
a  part  of  a  research  program  called  Performance  Evaluation  Test  for  Environ¬ 
mental  Research  (PETER). ^  This  research  program  requires  chat  each  test  be 
administered  to  each  subject  once  each  day  for  15  consecutive  workdays. 
Sequencing  of  tests  within  types  must  be  controlled  due  to  anticipated 
practice  effects.  Furthermore,  testing  facilities  are  limited  as  to  number, 
capacity  and  flexibility  in  changing  from  one  test  to  another.  Subjects 
must  be  scheduled  in  conformance  with  rules  governing  sequencing  of  tests 
and  in  compliance  with  constraints  imposed  by  facility  limitations. 

There  are  a  great  many  possible  schedules,  some  of  which  are  of  superior 
efficiency,  which  comply  with  all  the  constraints.  However,  manual  production 
of  a  "feasible"  schedule  (i.e.,  one  which  complies  with  all  constraints,  but 
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Kennedy,  R.S.  and  Bittner,  A.  C.,  Jr.  "The  Development  of  a  Navy 
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is  not  necessarily  optimal)  for  problems  of  this  magnitude  takes  a 
significant  amount  of  the  experimenter's  time.  Constructing  and  evaluating 
alternative  schedules  is  almost  prohibitive. 

Not  only  is  it  necessary  to  prepare  a  schedule  for  a  given  set  of  con¬ 
ditions,  but  also  it  may  be  necessary  to  revise  the  schedule  from  time  to 
time  to  reflect  the  impact  of  unforeseen  factors  which  may  temporarily  alter 
the  availability  of  subjects,  equipment  or  test  administration  personnel. 

In  addition,  it  is  desirable  to  be  able  to  assess  the  potential  impact  of 
policy  decisions  which  could  result  in  significant  long-term  or  permanent 
changes  in  the  number  of  subjects,  equipment  or  personnel  available  to  the 
performance  test  evaluation  project. 


B.  APPROACH 

The  dynamic  nature  of  the  scheduling  task  confronted  by  NAMRL  suggested 
the  development  of  a  computer  program  which  could  be  used  to  simulate  the 
environment  in  which  scheduling  takes  place  and  to  provide  an  algorithm  of 
flexibility  sufficient  to  cover  the  anticipated  range  of  input  values.  Such 
a  program  should  permit  the  user  to  construct  schedules  for  the  current  set 
of  resources  using  alternative  strategies,  to  evaluate  each  strategy  and  to 
select  the  most  satisfactory  one  for  implementation.  It  should  then  be 
possible  to  input  specific  real  data  (even  to  include  subject  names  and 
specific  dates  and  times)  and  produce  a  working  schedule  for  a  segment  of 
time. 

As  testing  proceeds,  new  runs  of  the  program  can  be  made  to  produce 
further  increments  of  the  schedule  which  reflect  actual  progress  up  to  that 
date.  Furthermore,  it  would  be  of  considerable  benefit  from  an  administrative 
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and  planning  standpoint  to  be  able  to  make  computer  simulation  runs  which 
assess  the  effects  on  project  completion  brought  about  by  the  gain  or  loss 
of  subjects,  equipment  or  personnel.  Such  a  simulation  capability  would 
permit  the  executive  user  to  answer  questions  concerning  the  expected  impact 
of  any  contemplated  resource  changes  and  to  evolve  strategies  to  optimize 
the  results. 

The  computer  program  which  evolved  from  this  effort  is  an  inplementation 
of  a  heuristic  scheduling  algorithm  that  provides,  for  a  specified  set  of 
conditions,  a  deterministic  solution.  The  program  logic  embodies  a  set  of 
user-specified  rules  and  constraints.  For  any  given  run  it  is  necessary  to 
provide  a  set  of  input  data  and  fix  the  values  of  certain  options.  The 
program  then  proceeds  systematically  on  a  day-by-day  and  period-by-period 
basis  to  construct  a  feasible  schedule. 

There  are  indications  that  this  heuristic  approach  is  a  practical  one 
for  the  relatively  complex  set  of  interacting  rules  involved  in  this  par¬ 
ticular  scheduling  task.  It  has  been  observed  that  it  is  impossible  to  find 
optimized  solutions  analytically  for  all  except  small  or  specially  constructed 
problems,  since  most  scheduling  problems  of  any  complexity  belong  to  the 
insoluble  class  of  problem  called  NP-complete.  "For  these  reasons  practitioners 
often  are  willing  to  settle  merely  for  a  feasible  schedule,  so  long  as  they 
have  some  indication  that  it  is  a  reasonably  good  one."^ 

The  approach  adopted  by  Desmatics  has  been  to  use  the  SCHEDULER  program 
to  make  several  runs  in  which  the  input  and  control  parameter  options  have 
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Garey,  M.  R.,  Graham,  R.  L.  and  Johnson,  D.  S.  "Performance  Guarantees 
For  Scheduling  Algorithms,"  Operations  Research.  Vol.  26,  No.  1,  January- 
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been  varied.  Comparison  of  the  results  provides  an  understanding  of  how 
schedule  efficiency  is  affected  by  variations  in  input  parameters. 


II.  PROGRAM  DESCRIPTION 


SCHEDULER  is  designed  to  construct  test  administration  schedules  for 
use  in  the  NAMRL  performance  test  research  program  described  in  the  previous 
section.  Although  its  use  is  not  necessarily  limited  to  this  particular 
application,  SCHEDULER  was  specifically  configured  to  meet  the  requirements 
of  the  performance  test  evaluation  scheduling  task.  It  is  readily  adaptable 
for  use  in  other  NAMRL  scheduling  requirements,  including  the  scheduling  of 
human  and  human  analog  subjects  for  impact  acceleration  and  vibration  experi¬ 
ment  runs. 

A.  INPUT  AND  THEORY  OF  OPERATION 

SCHEDULER  provides  for  the  production  of  schedules  in  which  up  to  ten 
tests  may  be  given  simultaneously.  The  program  assumes  that  there  are  up 
to  ten  sets  of  testing  facilities  in  which  tests  are  to  be  scheduled.  These 
facilities,  referred  to  here  as  "labs",  are  assumed  to  contain  the  equipment 
(chairs,  desks,  projectors,  tachistoscopic  displays,  rotary  pursuit  apparatus, 
or  other  facilities)  necessary  for  the  administration  of  a  particular  type 
of  performance  test.  Test  administration  personnel  are  also  considered  to  be 
part  of  each  lab  facility  for  purposes  of  scheduling.  That  is,  test  adminis¬ 
tration  personnel  are  not  treated  by  SCHEDULER  as  a  resource  independent  of 
the  lab  facilities. 

SCHEDULER  assumes  that  there  are  distinct  types  of  tests,  each  requiring 
a  particular  set  of  lab  facilities.  In  all  runs  of  SCHEDULER  made  to  date 
there  were  assumed  to  be  three  types  of  tests: 


(a)  Type  1,  individually  administered  tests, 

(b)  Type  2,  small-group  (apparatus  limited)  tests 
and  (c)  Type  3,  group  administered  tests. 

There  is  no  limit  to  the  number  of  types  which  may  be  defined,  but  as 
mentioned,  there  may  be  no  more  than  ten  labs. 

At  the  start  of  a  SCHEDULER  run  it  is  necessary  to  specify  what  type 
of  test  each  lab  is  set  up  to  accommodate.  This  lab  setup  must  remain  in 
effect  throughout  the  run.  This,  incidentally,  is  a  restriction  which  may 
possibly  limit  the  efficiency  of  the  current  version  of  SCHEDULER. 

SCHEDULER  permits  the  user  to  establish  a  priority  hierarchy  for  con¬ 
sideration  of  types  of  tests.  This  is  achieved  by  the  order  in  which  types 
of  tests  are  assigned  to  labs.  SCHEDULER  always  considers  labs  in  the  same 
fixed  sequence.  Thus,  if  the  user  specifies  that  the  first  of  three  labs 
is  to  be  set  up  for  individually-administered  tests,  the  second  for  small 
group  tests  and  the  third  for  group  tests,  then  individual  tests  will  have 
first  priority  and  group  tests  will  have  last  priority  when  it  comes  to 
allocating  subjects  to  tests  during  the  scheduling  run. 

SCHEDULER  performs  the  scheduling  operation  on  a  day-by-day  basis. 

Each  day  may  be  divided  by  the  user  into  a  fixed  number  of  periods.  The 
user  may  also  divide  the  periods  into  two  blocks  by  specifying  the  period 
which  is  to  start  the  second  block.  Scheduling  is  performed  with  respect 
to  "workdays"  within  an  internal  calendar,  which  must  be  defined  at  the 
start  of  each  run  and  linked  to  the  real  world  calendar  by  specifying  a 
particular  start  date,  which  may  be  in  the  past,  present  or  future.  The 
program  assumes  that  Monday  through  Friday  constitutes  the  normal  work 
week,  but  the  user  may  specify  another  range  of  days.  The  user  may  also 


specify  that  certain  days  are  holidays,  and  may  designate  certain  days  on 
which  some  or  all  of  the  subjects  are  expected  to  be  on  leave.  If  holidays 
and  leave  days  are  carefully  designated,  a  realistic  estimate  of  the  com¬ 
pletion  date  may  be  determined.  However,  if  only  the  length  of  the  schedule 
in  workdays  is  desired,  holidays  and  leave  days  may  be  ignored. 

Two  additional  types  of  input  data  are  required  for  a  run:  a  table  of 
tests  and  a  roster  of  subject  personnel.  The  test  table  designates  every 
test  required  to  be  scheduled  during  the  run  and  specifies  the  test  type. 
Each  test  may  have  other  tests  within  the  test  table  as  its  prerequisites. 

Up  to  120  tests  may  be  included  in  the  table  but  no  more  than  twenty  of 
these  may  have  prerequisites.  A  test  which  has  prerequisites  is  referred  to 
as  a  "milestone"  test.  Each  milestone  test  may  have  up  to  ten  other  tests 
from  the  table  as  prerequisites.  The  rule  governing  the  scheduling  of  mile¬ 
stone  tests  is  that  a  subject  may  not  be  scheduled  for  a  milestone  test 
administration  until  he  has  completed  all  of  the  required  administrations  of 
all  of  its  prerequisites.  However,  it  is  not  required  that  all  subjects 
complete  all  prerequisites  before  the  first  subject  may  be  scheduled  for  a 
milestone.  The  user  may  specify  for  each  test  a  date  on  which  that  test 
may  start.  The  program  will  not  schedule  any  test  until  its  start  date  has 
arrived.  Unless  otherwise  specified,  each  test  in  the  table  is  assumed  to 
be  available  at  the  start  of  the  run. 

The  user  must  provide  a  roster  of  subjects  who  are  to  be  scheduled  for 
all  tests  during  the  run.  Up  to  100  subjects  may  be  listed  in  the  roster. 
The  user  may  specify  for  each  subject  an  entry  date  and/or  an  exit  date. 

No  subject  will  be  scheduled  before  his  entry  date  nor  after  his  exit  date. 
(However,  exit  dates  are  not  used  in  establishing  priority  for  scheduling 
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of  subjects.)  In  the  absence  of  entry  and/or  exit  dates  a  subject  is 
assumed  to  be  available  throughout  the  run. 

Scheduling  proceeds  on  a  day-by-day,  period-by-period,  lab-by-lab 
basis.  At  the  start  of  each  day  the  program  examines  the  roster,  and  the 
calendar  for  several  days  in  the  future,  to  determine  which  subjects  are 
available  currently  and  for  enough  workdays  in  the  future  to  allow  them 
to  complete  the  required  number  of  consecutive  administrations  of  any  test 
which  might  start  on  that  day.  Indicators  within  the  computer  program  are 
set  accordingly  to  obviate  the  need  for  repeatedly  determining  availability 
for  each  period  and  each  lab. 

SCHEDULER  then  tries  to  find  a  test  to  be  scheduled  in  each  lab. 

Tests  scheduled  in  the  first  period  of  the  day  (or  the  first  period  of 
the  second  block  of  periods,  if  blocking  is  allowed)  cannot  be  replaced 
with  other  tests  during  later  periods  of  the  same  block.  However,  if  no 
test  can  be  scheduled  due  to  lack  of  subjects  (busy  or  done)  during  the 
first  period  of  a  block,  one  may  be  started  later  if  subjects  become  avail¬ 
able. 

SCHEDULER  gives  priority  to  tests  which  have  already  started  over  tests 
which  have  not.  This  is  accomplished  through  the  use  of  two  queues.  At 
the  start  of  a  run  SCHEDULER  loads  a  queue  of  startable  tests  with  the  test 
numbers  of  the  first  N  tests  from  the  test  table.  The  user  must  specify  the 
number,  N,  of  tests  which  may  be  active  at  one  time.  The  program  then  looks 
in  the  queue  of  started  tests  for  a  test  to  schedule  in  a  particular  lab. 

If  a  suitable  test  cannot  be  found  in  this  queue  it  looks  next  in  the  queue 
of  startable  tests.  If  a  test  is  found  which  is  of  the  right  type  for  the 
lab,  and  if  enough  subjects  can  be  found,  the  test  is  added  to  the  queue  of 


started  tests  and  removed  from  the  other  queue.  Since  the  program  looks 
first  in  the  queue  of  started  tests,  it  effectively  gives  priority  to 
started  tests  in  the  order  in  which  they  were  started.  The  maximum  number 
of  tests  which  can  be  active  at  once  is  limited  by  the  length  of  the  queues, 
which  is  120  tests. 

After  a  test  has  been  selected  for  scheduling,  the  program  tries  to 
find  subjects  to  be  tested.  Each  subject  must  be  scheduled  for  one  admin¬ 
istration  per  day  on  each  of  a  specified  number  of  workdays  (e.g.,  15 
consecutive  workdays).  SCHEDULER  accomplishes  this  by  maintaining  a  subjects- 
by-tests  table  called  LOGG  in  which  it  counts  the  number  of  administrations 
completed.  If  an  entry  is  zero  or  greater,  but  less  than  the  number  required, 
the  subject  needs  to  be  scheduled  for  the  test  in  question.  Once  a  subject 
is  scheduled,  his  LOGG  entry  is  incremented  and  set  negative  so  he  will  not 
be  rescheduled  that  day.  At  the  start  of  a  new  day  all  LOGG  entries  are 
reset  positive. 

After  a  subject  has  been  scheduled  for  a  test,  he  is  busy  for  that 
period  and  must  not  be  scheduled  for  another  test  in  another  lab  during  the 
same  period.  SCHEDULER  controls  the  conflict  problems  by  setting  a  busy 
indicator  for  each  subject  after  he  is  scheduled.  All  busy  indicators  are 
reset  at  the  start  of  the  next  period. 

The  previously  mentioned  test  table  also  must  specify  the  maximum 
number  of  subjects  which  can  be  tested  simultaneously  in  one  lab  for  a  given 
test.  This  table  may  also  be  used  to  set  the  minimum  number  of  subjects  to 
be  scheduled,  which  may  be  the  same  as  the  maximum  or  some  lesser  number. 

Using  the  minimum  group  size  option  and  setting  the  size  equal  to  one  for  all 
tests  is  an  alternative  scheduling  strategy  which  may  be  compared  with  requiring 
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the  maximum  group  size  in  all  cases. 

It  is  possible  to  specify  that  two  or  more  labs  are  of  the  same  type. 

This  is  particularly  applicable  if  it  is  desired  to  see  the  effect  of 
providing  additional  facilities  for  individually  administered  tests,  which 
are  the  bottleneck  in  most  situations.  SCHEDULER  provides  an  option  Intended 
to  improve  the  efficiency  of  schedules  produced  when  two  labs  have  been  set 
up  for  the  same  type  of  test.  To  apply  this  option  the  user  not  only  specifies 
the  type  of  test  for  which  each  lab  is  to  be  set  up,  but  also  indicates  the 
"dual-track"  relationship  of  the  two  labs  which  are  of  the  same  type.  With¬ 
out  this  feature  both  labs  would  be  scheduled  for  the  same  test,  but  when 
this  dual- track  option  is  applied,  the  program  checks  at  the  start  of  each 
block  of  periods  to  see  if  one  lab  of  the  pair  could  accommodate  all  the 
subjects  remaining  to  be  scheduled  for  a  given  test.  If  so,  the  second  lab 
is  then  available  to  be  scheduled  for  a  different  test. 

B.  OUTPUT 

The  SCHEDULER  program  as  it  currently  exists  is  capable  of  producing 
a  variety  of  outputs.  The  principal  output  is  a  printout  which  traces  the 
day-by-day,  period-by-period,  lab-by-lab  operation  of  the  algorithm.  The 
user  may  specify  the  degree  of  detail  produced  for  this  output.  At  one 
extreme  it  provides  a  list  of  the  names  of  the  subjects  scheduled  in  each 
lab  for  each  period  of  every  day  (see  Figure  1) .  At  the  other  extreme  it 
produces  only  a  listing  of  the  user-selected  options  (input  conditions) 
and  a  summary  of  the  final  results  at  the  end  of  the  run. 

Figure  2  is  an  example  of  some  of  the  information  provided  at  the  end 
of  a  typical  run.  The  upper  portion  summarizes  some  of  the  run  conditions. 
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Figure  2:  An  Example  of  Some  Information  Provided 
at  the  End  of  a  Typical  Run 
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Here  the  completion  date  was  Friday,  16  March  1979,  and  the  schedule 
required  90  workdays  to  complete.  The  four  labs  were  set  up  for  type 
(1,  1,  2,  3)  tests.  Lab  2  was  the  second  track  of  a  dual-track  pair,  of 
which  lab  1  was  the  first  track  (LABKEY(2)  =  1).  All  tests  (NQK  =  19)  were 
completed.  The  order  in  which  they  were  completed  was  (3,  2,  9,  1,...,  19). 

The  lower  portion  is  a  start/stop  table  which  lists  each  of  the  tests,  its 
type,  the  workdays  on  which  each  was  started  and  stopped  (completed)  and 
the  corresponding  calendar  dates  for  these  events.  In  contrast.  Figure  3 
shows  the  workdays  on  which  each  individual  subject  started  and  completed 
each  test  [e.g.,  subject  1  started  test  1  (a  type  1  test)  on  the  first 
workday  and  completed  it  on  the  fifteenth].  This  table  is  useful  in  confirm¬ 
ing  compliance  with  the  rule  which  requires  that  once  a  subject  starts  a 
test  he  must  be  scheduled  for  N  consecutive  workdays. 

Figure  4  is  a  bar  graph  for  tests  versus  workdays  which  shows  the  phasing 
of  tests  within  the  schedule.  The  numbers  which  make  up  the  bars  are  the 
test  type  codes.  Thus,  Figure  4  shows  that  test  1  is  a  type  1  test  (individ¬ 
ually  administered)  which  was  scheduled  on  the  first  through  fifteenth  workdays. 
Tests  2  and  3  are  types  2  and  3  respectively  (small  group  and  group  administered), 
which  also  were  scheduled  on  the  first  through  fifteenth  workdays.  Test  4 
also  is  a  type  1  test,  but  its  administration  was  not  completed  until  the  30th 
workday.  Just  how  this  happened  may  be  seen  by  referring  back  to  Figure  3, 
which  shows  that  the  first  five  subjects  were  scheduled  for  test  4  during  the 
first  through  fifteenth  workdays  and  the  rest  of  the  subjects  were  scheduled 
for  the  sixteenth  through  thirtieth  workdays. 

Figure  4  also  shows  that  a  total  of  six  tests,  two  of  each  type,  were 
scheduled  each  of  the  first  thirty  days,  while  only  five  were  scheduled  the 
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Figure  3:  Start/Stop  Workdays  for  Individual  Subjects 
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31st  through  45th.  Thereafter,  only  two  or  three  tests  were  active 
simultaneously.  Because  of  computer  printer  line  length  limitations, 
bar  graphs  produced  by  SCHEDULER  are  restricted  to  cover  only  the  first 
120  days  of  any  run.  However,  only  90  days  have  been  reproduced  here. 

Figure  5  is  a  plot  which  shows  the  percentage  of  schedule  completion  as 
a  function  of  time  in  workdays.  The  legend  indicates  when  the  run  was 
made  and  the  program  version  used.  It  also  summarizes  the  input  conditions 
employed,  including  the  test  type  for  which  each  lab  was  set  up  and  the 
priority  sequence  used.  The  start  and  stop  dates  are  shown,  as  well  as  the 
number  of  workdays  and  the  percentage  completion  at  the  end  of  the  run. 
"Utilization"  is  the  fraction  of  the  total  available  lab  periods  (periods  x 
labs  x  workdays)  actually  used.  Had  the  schedule  not  been  completed  at  the 
end  of  the  run  (as  when  the  run  exceeds  the  allowed  amount  of  computer  time) , 
the  legend  would  also  have  included  a  list  of  the  tests  still  active  and  a 
list  of  the  tests  completed,  in  the  order  of  completion. 

The  item  "10  MAX"  in  the  legend  refers  to  the  maximum  number  of  total 
administrations  per  day  for  all  tests  which  each  subject  is  allowed.  Unless 
specified  by  the  user,  this  value  defaults  to  the  number  of  periods  there 
are  in  a  day.  Thus  in  this  case  each  subject  was  allowed  to  be  scheduled 
once  in  each  of  the  ten  periods  of  every  day  (but  only  once  a  day  for  each 
specific  test).  The  end-of-run  output  also  includes  a  frequency  distribution 
table  (not  shown  here)  which  provides  an  indication  of  the  average  number  of 
administrations  per  day  each  subject  was  scheduled. 

If  more  information  is  required,  the  program  produces  detailed  printed 
output  showing  precisely  which  subjects  were  scheduled  in  each  lab  for  each 
period  of  every  day.  The  detailed  output  also  indicates  the  contents  of 
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t». 2  two  queues  at  the  end  of  each  period  and  shows  which  tests  were 
considered  when  making  test  assignments  to  labs. 

C.  ADDITIONAL  OPTIONS  AND  CAPABILITIES 

An  option  is  provided  which  allows  SCHEDULER  to  simulate  the  random, 
short-duration  unavailability  of  individual  subjects,  as  might  be  the  case 
when  a  subject  is  on  sickcall  for  a  day.  A  similar  option  permits  simula¬ 
tion  of  random  short-term  unavailability  of  individual  lab  facilities,  as 
might  be  the  case  when  an  equipment  failure  is  experienced.  To  activate 
either  of  these  options,  the  user  must  supply  probability  thresholds.  The 
program  then  generates  a  random  number  each  time  a  subject  or  lab  is  con¬ 
sidered.  If  the  random  number  exceeds  the  threshold  specified  for  subject 
unavailability  or  for  an  outage  in  a  particular  lab  (separate  thresholds 
may  be  set  for  each  lab),  the  subject  or  lab  is  bypassed  temporarily. 

Another  option,  the  dump/restart  feature,  permits  the  user  to  cause 
intermediate  results  to  be  output  to  intermediate  storage  at  the  end  of 
a  specified  number  of  weeks.  The  run  may  then  continue  to  the  completion  of 
the  schedule,  at  which  time  the  final  results  will  be  printed.  By  specify¬ 
ing  a  high  level  of  detail,  the  user  can  cause  the  intermediate  results  to 
be  output  to  intermediate  storage  at  the  end  of  a  specified  number  of  weeks. 
The  run  may  then  continue  to  the  completion  of  the  schedule,  at  which  time 
the  final  results  will  be  printed.  By  specifying  a  high  level  of  detail, 
the  user  can  cause  the  production  of  a  working  schedule  for  the  period  prior 
to  the  interruption  point,  as  was  shown  in  Figure  1.  After  this  point  the 
level  of  detail  can  be  reduced  so  that  further  printing  will  be  suppressed 
until  the  end  of  the  run. 
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Later,  as  the  end  of  the  working  schedule  approaches  in  real  time, 
the  user  can  make  a  new  run  of  the  SCHEDULER  program  which  can  start  at  the 
interruption  point.  If  the  actual  testing  progress  does  not  match  the 
plan  produced  by  SCHEDULER,  the  user  can  make  any  necessary  adjustments  in 
the  data  which  was  put  in  temporary  storage  and  use  this  as  the  basis  for 
another  run  which  continues  from  the  interruption  point.  Items  not  requir¬ 
ing  adjustment  can  be  used  unchanged  in  restarting  the  run. 
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III.  EXPERIMENTAL  RUNS 


During  the  development  of  SCHEDULER,  a  series  of  runs  was  made  in  which 
many  of  the  parameters  were  fixed  in  value  while  others  varied  from  run  to 
run.  This  section  describes  the  run  conditions  and  discusses  the  results. 

A.  COMMON  CONDITIONS 

All  runs  employed  the  same  set  of  nineteen  tests,  seven  of  which  were 
individually-administered  tests.  Six  small-group  tests  and  six  group- 
administered  tests  were  also  Included.  These  nineteen  tests  were  listed  in 
a  fixed  rotational  sequence  (individual,  small-group,  group).  Every  sixth 
test  was  defined  as  a  "milestone"  test  which  had  the  five  Immediately  preceding 
tests  as  prerequisites.  Since  every  third  test  was  a  group-administered  test, 
every  milestone  test  was  thus  also  a  group  test,  although  not  all  group  tests 
were  milestones. 

All  runs  employed  four  laboratory  facilities  with  the  labs  set  up  so 
that  the  first  two  could  each  accommodate  individually-administered  tests. 

The  third  lab  was  set  up  for  small-group  tests  and  the  fourth  lab  for  group 
tests.  This  essentially  gave  highest  priority  to  individually-administered 
tests  and  lowest  priority  to  group-administered  tests.  Every  test  was 
allowed  to  be  scheduled  for  as  few  as  one  subject  after  trying  to  get  as 
many  subjects  as  possible.  Subjects  were  not  limited  in  the  number  of  tests 
taken  per  day,  but  of  course  no  subject  was  allowed  to  take  the  same  test 
more  than  once  in  the  same  day.  Except  as  noted  later,  every  subject  was 
required  to  be  scheduled  for  fifteen  consecutive  administrations  of  each 
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A  maximum  of  eighteen  tests  were  allowed  to  be  active  at  one  time; 
thus  the  nineteenth  test  could  not  be  started  until  all  subjects  had 
completed  test  1.  The  first  workday  was  Monday,  6  November  1978.  The 
longest  run  took  135  workdays.  Within  this  period  there  were  six  holidays 
but  no  leave  days.  The  runs  that  were  made  always  used  an  even  number  of 
periods  per  day.  The  "blocking"  option  was  employed  to  divide  the  days 
into  two  time  period  blocks  of  equal  size.  The  "dual- track"  option  was 
used  in  all  runs  to  allow  scheduling  a  different  test  in  the  second  lab  if 
it  were  found  that  the  first  lab  could  accommodate  all  the  subjects  still 
to  be  tested  within  the  periods  r chaining. 

The  choice  of  the  specific  conditions  outlined  above  reflects  some 
conclusions  evolved  during  early  development  and  testing  of  the  SCHEDULER 
program,  as  well  as  the  development  of  additional  capability  options  which 
have  since  been  incorporated  into  the  program.  For  instance,  it  is  now 
clear  that  the  better  priority  scheme  is  to  give  preference  to  the 
individually-administered  tests  which  constitute  the  bottleneck,  rather 
than  to  give  priority  to  the  group  tests  which  are  capable  of  accommodating 
more  subjects  at  one  time. 

B.  RUN  RESULTS 

Ten  major  runs  are  described  in  this  section.  The  principal  variables 
are  the  number  of  subjects  and  the  number  of  periods  per  day.  Runs  were 
made  for  eight  and  ten  periods  per  day  and  for  nine,  ten,  fourteen,  eighteen 
and  twenty  subjects.  The  runs  with  eighteen  or  twenty  subjects  and  eight  or 
ten  periods  correspond  most  closely  to  the  conditions  under  which  performance 


testing  is  now  being  carried  out  at  NAMRL.  Runs  were  also  made  for  the 
same  numbers  of  periods,  but  for  half  as  many  subjects,  to  see  what  might 
result  if  the  subjects  were  divided  into  two  groups  and  tested  at  two 
different  times.  A  run  with  fourteen  subjects  was  also  made  to  facilitate 
interpolation  between  the  nine-ten  subject  runs  and  the  eighteen-twenty 
subject  runs,  in  hope  of  identifying  a  clear  break  point  in  schedule  length 
as  a  function  of  the  number  of  subjects. 

Figure  6  summarizes  the  results  obtained  for  the  runs  undertaken,  as 
a  function  of  the  number  of  periods  per  day  and  the  number  of  subjects. 

The  principal  evaluation  measure  is  the  number  of  workdays  required  to 
complete  the  schedule.  This  is  shown  in  the  center  of  each  cell.  The 
number  in  the  upper  left  corner  of  each  cell  is  the  utilization  factor,  the 
number  in  the  upper  right  is  the  average  number  of  administrations  per 
subject  per  day,  the  number  in  the  lower  left  corner  is  the  maximum  number 
of  administrations  any  subject  had  in  any  day,  and  the  number  in  the  lower 
right  corner  is  the  average  number  of  administrations  per  day. 

The  length  of  the  schedules  produced  for  the  sets  of  conditions 
examined  here  is  most  sensitive  to  the  manner  in  which  scheduling  of  the 
individually-administered  tests  can  be  accomplished.  Because  there  are 
seven  individually-administered  tests,  each  requiring  fifteen  consecutive 
administrations,  the  schedule  will  of  necessity  be  105  days  long  (15  x  7) 
if  the  number  of  subjects  and  periods  per  day  allow  exactly  one  individually- 
administered  test  to  be  given  at  a  time.  Such  is  the  case  when  the  number 
of  periods  per  day  times  the  number  of  labs  dedicated  to  individually- 
administered  tests  is  at  least  equal  to  the  number  of  subjects.  In  ten 
periods,  two  labs  can  process  twenty  subjects  per  day  through  one 
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individually-administered  test. 

When  the  number  of  subjects  is  ten  or  less  it  is  possible  for  two 
labs  to  process  all  subjects  through  two  individually-administered  tests 
per  ten-period  day.  Since  there  are  seven  such  tests  to  be  scheduled,  it 
takes  sixty  days  to  process  nine  or  ten  subjects.  It  should  be  noted  that 
eight  individually-administered  tests  could  also  be  completed  in  60  workdays. 

When  there  are  fourteen  subjects  and  ten  periods  per  day  it  is  possible 
to  complete  the  schedule  in  90  days  because  partial  overlapping  of 
individually-administered  tests  can  be  achieved.  This  may  be  seen  by  refer¬ 
ring  back  to  Figure  3  and  its  accompanying  discussion. 

Restricting  the  number  of  periods  per  day  to  eight  causes  the  schedule 
length  to  be  extended.  With  nine  or  ten  subjects  it  is  not  possible  for  all 
subjects  to  complete  two  individually-administered  tests  per  day.  While  the 
majority  can,  the  remainder  must  be  held  over  into  the  next  fifteen-day  span. 
The  resultant  partial  overlapping  of  tests  causes  the  scheduling  of  nine  or 
ten  subjects  in  eight  periods  per  day  to  take  90  workdays.  The  schedules 
for  fourteen,  eighteen  and  twenty  subjects  are  similarly  extended,  as  may  be 
seen  in  Figure  6. 

C.  ABBREVIATED  RUNS 

Additional  runs  were  made  to  investigate  the  feasibility  of  using  abbre¬ 
viated  runs  to  simulate  long  schedules.  A  glance  at  Figure  4,  which  is  a 
fairly  typical  test-phasing  bar  graph,  shows  that  there  is  considerable 
redundancy  within  spans  of  fifteen  days.  Days  one  through  fifteen  are 
identical,  as  are  days  sixteen  through  thirty.  Except  for  days  46,  60  and 
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90  which  are  unique,  there  is  a  great  deal  of  redundancy.  The  reason 
that  certain  days  seem  unique  is  that  on  the  45th  day,  for  example,  most 
of  the  subjects  completed  the  last  administration  of  a  prerequisite  test  in 
the  first  block  of  the  day,  enabling  them  to  be  scheduled  for  milestone  test 
12  in  the  first  afternoon  period  of  the  45th  day.  A  similar  situation  occurs 
on  the  60th  day. 

It  seemed  distinctly  possible  that  the  results  of  this  run  could  have 
been  obtained  by  appropriate  extrapolation  from  another  run,  identical  in 
every  respect  except  that  it  required  only  three  administrations  of  each  test, 
or  even  only  one  administration.  To  test  this  possibility,  three  of  the  runs 
described  in  the  preceding  section  were  rerun  with  identical  parameters  except 
that  the  number  of  administrations  required  was  reduced  from  fifteen  to  three. 

In  addition,  one  of  those  was  also  run  with  one  administration.  In  Figure  6, 
the  runs  which  were  repeated  are  the  ones  for  ten  subjects  with  eight  periods 
per  day,  twenty  subjects  for  ten  periods,  and  fourteen  subjects  for  ten  periods. 

The  results  of  these  reruns  were  as  anticipated.  The  total  lengths  of 
the  three  administration  schedules  were  one-fifth  as  long  as  their  fifteen- 
administration  counterparts,  utilization  factors  were  Identical,  and  the  test 
phasings  were  comparable  (for  individual  subjects  as  well  as  tests  as  a  whole). 
Figure  7  shows  a  comparison  of  the  bar  graphs  for  the  three  runs  made  using 
fourteen  subjects  and  ten  periods.  The  upper  portion  shows  the  fifteen- 
administration  run  which  required  90  workdays,  while  the  lower  half  shows  the 
comparable  three-administration  and  one-administration  runs  which  took 
eighteen  workdays  and  six  workdays  respectively.  Note  that,  except  for  duration, 
the  phasing  is  identical. 

Whether  valid  extrapolation  could  be  accomplished  consistently  in  a  run 
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Figure  7:  Comparison  of  Phasing  for  Fifteen  Versus  Three  Versus  One  Administration ( 
for  Ten  Subjects  and  Eight  Periods  Per  Day 


requiring  only  one  administration  has  not  been  established.  However,  it 
appears  that  the  total  length  of  a  run  is  unaffected  by  occasional  early 
starts,  and  is  primarily  determined  by  the  manner  in  which  bottleneck 
(individually-administered)  tests  can  be  handled  under  a  given  set  of  run 
conditions.  In  some  instances  these  tests  must  be  run  end-to-end,  while 
in  other  circumstances  they  can  be  doubled  up  or  partially  overlapped.  In 
every  instance  seen  to  date,  the  total  length  of  the  schedule  has  turned  out 
to  be  a  multiple  of  the  number  of  administrations  required  for  each  test. 
Thus  it  seems  likely  that  this  type  of  extrapolation  would  prove  feasible, 
even  when  only  one  administration  was  required. 
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IV.  CONCLUSIONS 


Based  on  the  runs  described  in  the  previous  section,  plus  some  pre¬ 
liminary  runs  made  during  program  development,  certain  general  conclusions 
are  possible  concerning  the  type  of  scheduling  for  which  the  SCHEDULER 
algorithm  was  designed.  Individually-administered  tests  obviously  constitute 
a  bottleneck.  Where  there  is  a  choice,  group-administered  tests  are  pre¬ 
ferred,  other  considerations  being  equal.  Where  it  is  feasible  to  do  so, 
providing  duplicate  facilities  for  individually-administered  tests  greatly 
reduces  the  schedule  length. 

Given  the  mix  of  test  types  and  the  number  of  tests  within  types 
employed  in  these  runs,  there  are  certain  strategies  which  are  superior.  It 
seems  reasonable  to  say  that  allowing  small-group  and  group  tests  to  be 
scheduled  at  less  than  capacity  is  a  good  strategy.  Since  all  runs  described 
here  employed  this  rule  it  is  not  possible  to  show  its  superiority  to  a  rule 
requiring  full  capacity  to  be  maintained,  but  in  any  situation  where  some 
subjects  are  already  assigned  to  Individual  tests  it  would  not  be  possible 
to  schedule  a  group  test  at  the  same  time  if  a  full  capacity  rule  were  to  be 
enforced. 

It  is  best  to  give  first  priority  to  individually-administered  tests 
and  last  priority  to  group  tests.  Alternatives  were  found  to  be  inferior. 

When  group  tests  have  priority  they  capture  all  the  subjects,  causing  the 
other  labs  to  sit  idle. 

Inefficiency  results  when  it  is  not  permitted  to  change  tests  once  they 
have  been  set  up  for  the  day,  because  the  labs  become  idle  for  lack  of  subjects 


after  a  few  periods.  It  was  found  to  improve  efficiency  if  the  day  can 
be  divided  into  two  blocks  of  time  periods.  When  the  number  of  subjects  is 
sufficiently  small,  blocking  allows  completion  of  two  tests  of  each  type 
per  workday. 

It  was  also  observed  that  improved  efficiency  results  when  the  schedul¬ 
ing  is  coordinated  between  two  labs  set  up  for  the  same  type  of  test.  There 
are  times  when  two  labs  should,  if  possible,  administer  the  same  test. 

However,  there  are  other  times  when  it  is  more  efficient  to  change  over  the 
second  lab  to  another  test  when  it  is  determined  that  the  first  lab  has  the 
capacity  to  carry  the  load  alone. 

The  runs  described  here  tend  to  indicate  that  the  number  of  tests  any 
subject  can  be  expected  to  take  is  probably  not  excessive.  As  Figure  6  shows, 
the  maximum  number  of  administrations  per  subject  per  day  was  six.  The 
highest  average  in  any  run  was  5.81  per  day. 

Efficiency  in  terms  of  either  the  utilization  factor  or  the  average 
number  of  administrations  per  day  is  somewhat  deceptive  because  it  would  be 
possible  to  add  selected  tests  to  the  task  which  would  fill  up  the  schedule 
without  increasing  its  length.  The  best  efficiency  measure  would  seem  to  be 
the  number  of  workdays  required  to  complete  a  given  schedule. 


V.  SUGGESTED  FUTURE  DEVELOPMENT 

The  SCHEDULER  program  as  it  now  exists  must  be  considered  a  working 
and  partially  tested  feasibility  model  which  runs  in  a  particular  environ¬ 
ment.  Although  written  primarily  in  IBM  FORTRAN  IV  language  which  implies 
a  considerable  degree  of  portability,  it  employs  a  few  routines  peculiar 
to  the  environment  in  which  it  was  developed.  Adapting  the  program  for 
other  installations  would  require  some  modification. 

As  a  feasibility  model,  SCHEDULER  does  not  achieve  optimized  allocation 
of  subjects  to  tests.  In  this  respect  it  is  estimated  that  an  improved  version 
could  suboptimize  the  allocation  of  subjects  on  a  period  by  period  basis  by 
producing  alternative  schedules  within  each  period  and  selecting  the  one 
which  provides  the  greatest  number  of  administrations  per  period.  In  essence, 
instead  of  using  a  fixed  priority  sequence  for  types  of  tests,  it  would  select 
the  best  allocation  within  each  period  after  trying  various  possibilities. 

Such  a  procedure  can  be  expected  to  provide  an  improvement  in  the  efficiency 
of  the  schedules  produced,  but  at  the  cost  of  increased  computer  running  time. 

It  may  be  possible  to  offset  this  increase  in  running  time  by  further 
experimenting  with  the  algorithm  to  develop  techniques  for  breaking  runs  into 
phases.  It  would  seem  feasible  to  identify  distinct  phases  in  each  simulation 
run,  such  as  start-up,  mid-period  and  ending  phase.  If  the  mid-phase  is 
found  in  general  to  be  a  steady-state  period,  it  should  be  possible  to  extrap¬ 
olate  from  data  obtained  in  a  short  sample  of  mid-period  activity  so  that 
relatively  short  computer  runs  could  be  used  to  simulate  relatively  long 
scheduling  tasks.  This  is  based  on  the  assumption  that  distinct  phases  exist 
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in  typical  schedules  and  that  they  can  be  identified. 

The  runs  made  to  date  were  designed  to  provide  a  demonstration  of  the 
major  features  of  the  algorithm,  rather  than  being  necessarily  representative 
of  real  scheduling  tasks  in  all  respects.  In  particular,  these  runs  employed 
a  limited  number  of  tests,  whereas  the  NAMRL  performance  testing  program  is 
an  on-going  operation.  The  essential  difference  is  that  early  in  each  experi¬ 
mental  run  of  SCHEDULER  the  algorithm  begins  to  run  out  of  certain  types  of 
tests,  so  that  a  great  portion  of  each  run  could  be  considered  to  be  within 
the  end  phase.  After  30  to  45  days,  most  of  the  group  tests  and  small  group 
tests  have  been  completed  and  the  majority  of  the  remaining  time  is  devoted 
to  individual  tests  and  those  group  tests  which  are  also  milestones.  If 
there  were  more  small  group  and  group  non-milestone  tests  to  be  scheduled, 
the  steadily  diminishing  efficiency  noted  in  most  of  the  runs  would  be  post¬ 
poned  until  the  very  end  of  the  run. 

It  is  desirable  that  any  extrapolation  technique  employed  be  readily 
applicable  to  the  data  obtained  from  a  run.  The  labor  required  in  the  extrap¬ 
olation  should  not  outweigh  the  cost  of  the  comparable  full  computer  run. 

It  is  expected  that  the  extrapolation  could  either  be  accomplished  with  a 
minimum  of  human  effort  or  could  be  carried  out  automatically  at  the  end  of 
each  computer  run. 

One  problem  anticipated  in  extrapolation  from  abbreviated  runs  is  that 
they  would  have  to  be  run  strictly  with  respect  to  workdays,  since  holidays 
and  leave  days  would  be  a  complicating  factor.  Holidays  perhaps  could  be 
taken  into  account  in  determining  a  specific  end  date,  but  leave  days  might 
constitute  a  more  difficult  problem,  since  the  algorithm  looks  ahead  to 
insure  that  no  subject  starts  a  test  that  may  be  interrupted  by  leave.  It 
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APPENDIX  I;  PROGRAM  DESCRIPTION 


SCHEDULER  was  written  in  IBM  360/370  FORTRAN  IV  language  and  was  run 
under  the  IBM  OS  operating  system  using  the  RJE  remote  job  entry  system. 

The  installation  in  which  jobs  were  run  allows  extensive  use  of  disk-stored 
card  image  input/output  files.  Advantage  was  taken  of  this  capability  by 
routing  different  types  of  output  to  separate  files.  Similarly,  different 
types  of  input  data  were  placed  in  separate  disk  files  and  read  from  separate 
units. 

A.  INPUT/OUTPUT  FILES 

Symbolic  unit  designation  was  employed  to  facilitate  changing  the 
physical  unit  designation  if  necessary,  since  units  are  assigned  specific 
values  in  a  BLOCK  DATA  Subroutine.  These  assignments  follow  a  pattern.  All 
units  are  designated  by  the  letter  U  (defined  as  an  integer)  followed  by  one 
or  two  digits.  All  units  ending  in  5  are  card  reader-like  devices  specified 
as  disk  files  having  80-character  record  lengths  (of  which  only  72  are  used). 
All  units  ending  in  6  are  printer-like  output  devices  (defined  as  disk  files) 
having  133-character  line  lengths,  the  first  character  of  which  is  an  IBM 
carriage  control  character.  All  units  ending  in  7  are  card  punch-like  devices 
(defined  as  disk  files)  having  80-character  record  lengths.  Figure  A1  is  a 
table  of  Input/Output  files  used  in  SCHEDULER, 

Figure  A2  gives  the  makeup  of  the  input  decks  read  by  units  U5  and  U25, 
showing  the  sequence  in  which  items  are  read.  Among  other  things,  the  control 
cards  must  specify  whether  there  is  a  probabilities  card  or  not  and  the  number 


FILE  DESIGNATORS,  TYPES  AND  FUNCTIONS 


SYMBOL  TYPE 


FUNCTION 


U5  - READ 

U6  - PRINT 

U7  - PUNCH 

U16 - PRINT 

U25 - READ 

U26 - PRINT 

U27 - PUNCH 

U35 - READ 

U36 - PRINT 

U37 - PUNCH 

U45 - READ 

U47 - PUNCH 

U57 - PUNCH 

U65 - READ 

U67 - PUNCH 


-  INPUT  CONTROL  CARDS,  SUBJECTS  &  TESTS 

-  OUTPUT  DAILY  SCHEDULE  &  BAR  GRAPH 

-  OUTPUT  LOGG  ARRAY  FOR  RESTART  (OPT.) 

-  PRINT  CALENDAR 

-  INPUT  CALENDAR  SPECIAL  DATES 

-  PRINT  DETAILED  DIAGNOSTICS 

-  OUTPUT  QUEUES,  ETC.  FOR  RESTART  (OPT.) 

-  INPUT  LOGG-ARRAY  FOR  RESTART  (OPT.) 

-  PRINT  FINAL  RESULTS  (TEST  START/STOPS,  ETC.) 

-  OUTPUT  DATA  FOR  PLOT  OF  2  COMPLETED 

-  INPUT  QUEUES  FOR  RESTART 

-  OUTPUT  LEGEND  FOR  PLOT  TITLE 

-  PRINT  SUBJECT  START/ STOP  TABLE 

-  INPUT  START/STOPS  FOR  RESTART  (BINARY) 

-  OUTPUT  START/STOPS  FOR  RESTART  (BINARY) 


INPUT  &  OUTPUT  FILES  BY  CLASS,  UNIT  NO.  AND  PROGRAM  SEGMENT 


CLASS'*- 
UNIT-*- 
PROGRAM  SEGMENT 
MAIN 
DAYER 
LSTLOG 
CALEND 
LOGGER 
LOGOUT 
PLOTER 
FREEKY 
BARGRF 
BLOCK  DATA 


CARD  INPUT  PRINT  PUNCH 


Figure  Al:  SCHEDULER  Input  and  Output  Files 
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UNIT  US 


Figure  A2:  SCHEDULER  Input  Card  Sequence 


of  subject  cards  and  milestone  cards  included.  Calendar  cards,  if  any, 
are  read  from  unit  25  before  subject  cards  are  read  from  unit  5.  When 
an  end-of-file  is  detected  on  unit  25,  reading  continues  on  unit  5,  so  it 
is  not  necessary  to  specify  the  number  of  date  cards  included  in  unit  25. 

All  reading  is  done  in  the  MAIN  program,  except  for  reading  of  restart 
files  which  is  done  in  subroutine  LOGGER. 

Figures  A3  through  All  show  the  field  formats  of  the  control  cards 
and  various  data  input  cards.  The  title  card  (not  shown)  is  free  format. 

It  allows  up  to  72  characters  of  title  or  other  identification  to  be  printed 
on  all  outputs. 

B.  INSTALLATION  DEPENDENT  CODE  AND  OTHER  LIMITATIONS 

SCHEDULER  is  known  to  present  certain  portability  problems,  particularly 
when  attempting  to  convert  to  a  UNIVAC  machine.  One  of  these  is  the  use  of 
symbolic  device  names  in  I/O  statements.  Others  include  the  use  of  logical 
operators  in  LOGICAL  IF  statements  and  the  use  of  literals  enclosed  in  single 
quotes.  Perhaps  the  most  troublesome  might  be  the  extensive  use  of  nested 
subscripts,  as  in 

IN  =  J(K(L(M))) 

which  must  be  rewritten  as 

N  «  L(M) 

I  »  K(N) 

IN  *  J(I)  . 

In  addition  there  are  a  number  of  installation-dependent  routines 
employed  in  SCHEDULER,  some  of  which  are  not  essential  and  can  be  eliminated, 
such  as  the  use  of  an  interval  timer.  Others,  such  as  the  use  of  local 
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RECORD  TITLE:  CONTROL  CARD  NO.  1  UNIT:  U5  FORMAT  STATEMENT 

C .  ^  •  ‘  •  \  '  'f  '  •  7“  '  ,  u  \ .  ; 

/  ;V*  ‘.K  '  ./  'v  .  .  (■  .  -  > 

FIELD  NAME  FORMAT  POSITIONS  CONTENTS 

•  ..  •  .  t  -  -  ■  v  ■'  T  -.1  - 

t.  V  ...  -  7 .  v  ’I  •  •  7  .  '  '  - 

NWEEKS  15  1-5  Length  of  calendar  in  weeks 

NO.:  20 

v 

MAX.  VALUE 

208 

NTESTS 

15 

6-10 

Number  of  tests 

120 

* 

NSUBJS 

15 

11-15 

Number  of  subjects 

100 

NSLOTS 

15 

16-20 

Number  of  periods  per  day 

— 

NLABYS 

15 

21-25 

Number  of  laboratories 

10 

NADMIN 

15 

26-30 

No.  of  admins,  required  per  test: 

Defaults  to  15  if  blank  or  zero 

If  >  0,  provides  default  for  test  cards 

If  <  0,  overrides  values  on  test  cards 

NORANGE 

15 

31-35 

Number  of  tests  allowed  active  at  once 

100 

NLINKS 

15 

3  6- 40 

Number  of  tests  which  are  "milestones" 

20 

MINGSZ 

15 

A1-A5 

"Min.  group  size"-option  switch: 

If  <  0,  option  not  used 

If  >  0,  option  is  used 

™ 

MAXTST 

15 

46-50 

Max.  No.  of  tests  per  day  anyone  may  take 

— 

MAVAIL 

15 

51-55 

Subject  "unavailability"  simulation  switch: 
If  >  0,  subject  unavailability  simulated 

If  £  0,  option  not  used 

MOUTAG 

15 

56-60 

Lab.  "outage"  simulation  switch: 

If  >  0,  lab  outages  simulated 

If  £  0,  option  not  used 

LSTLOW 

15 

61-65 

Listing  level  to  be  used  after  a  Dump 

— 

• 

MCPRNT 

15 

66-70 

Controls  calendar  printing: 

208 

If  _<  0,  calendar  not  printed 
If  >  0,  MCPRNT  weeks  are  printed 


Figure  A3:  Record  Format  for  Control  Card  No.  1 
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RECORD  TITLE:  CONTROL  CARD  NO.  2  UNIT:  U5  FORMAT  STATEMENT  NO.:  22 


FIELD  NAME 

FORMAT 

POSITIONS 

CONTENTS 

MAX.  VALUE 

START 

8A1 

1-8 

Calendar  starting  date  (MM/DD/YY) 

— 

PHYRST 

8A1 

11-18 

First  date  of  testing  (MM/DD/YY) 

Must  be  a  Monday 

Defaults  to  first  Monday  after  START 

• ™ — 

LASTWK 

15 

21-25 

Max.  weeks  this  run  may  take 

208 

NEWDAY 

15 

26-30 

First  workday  of  week  (2=Mon.) 

Defaults  to  2  (Monday) 

7 

LASTDY 

15 

31-35 

Last  workday  of  week  (6=Fri.) 

Defaults  to  6  (Friday) 

7 

NORULE 

15 

36-40 

Switch  controls  unrestricted  scheduling: 

If  =  0,  option  not  used 

If  f  0,  tests  may  be  changed  anytime  in 
any  lab 

LOGGIN 

15 

41-45 

Controls  reading  dumped  files: 

If  <  0,  dumped  files  not  read 

If  >  0,  this  is  a  restart  run 

LOGDMP 

15 

46-50 

Controls  writing  dump  files  for  restart 

If  <_  0,  files  are  not  dumped 

If  >  0,  files  will  be  dumped  at  end  of 
the  LOGDMP th  week 

208 

IBLOCK 

15 

51-55 

Controls  splitting  day  into  2  blocks  of 
periods: 

If  _<  0,  no  blocking  takes  place 

If  >  0,  2nd  block  starts  in  lBLOCKth 
period 

MINGO 

15 

56-60 

Controls  writing  details  to  Unit  U26 
Specifies  week  when  detail  Increases 
(Before  MINGO,  detail  is  minimal; 

After  MINGO  it  greatly  increases) 

208 

LSTLVL 

15 

61-65 

Controls  level  of  detail  written  to  Unit  U6 
Ten  levels  are  possible.  Low  LSTLVL  gives 
least  detail.  LSTLVL  of  4  or  more  prints 
daily  schedule  with  names. 

NRACRS 

12 

66-70 

Controls  no.  of  names  listed  on  each  line. 
Maximum  is  10.  Default  is  10. 

— 

Note:  See  Figure  A6  note  on  date  formats 


Figure  A4:  Record  Format  for  Control  Card  No.  2 
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RECORD  TITLE: 


PROBABILITIES  CARD 


UNIT:  U5 


FORMAT  STATEMENT  NO.: 


260 


FIELD  NAME 

FORMAT 

POSITIONS 

CONTENTS 

MAX.  VALUE 

PRUNAV 

F5.3 

1-5 

Probability  that  a  subject  is  temporarily 
unavailable  (for  one  day) 

1.000 

IBASE 

110 

11-20 

Seed  for  starting  random  number  generator. 
Default  value  is  provided  by  subroutine  if 
no  user  seed  is  given. 

231-1 

PROUTS(I) 

10F6.3 

21-75 

Probability  that  lab  has  temporary  outage 
(one  value  for  each  of  up  to  10  labs) 

1.000 

Figure  A5:  Record  Format  for  Probabilities  Card 


RECORD  TITLE:  CALENDAR  SPECIAL  DATE  CARD 


UNIT;  U25 


FORMAT  STATEMENT  NO.:  305 


FIELD  NAME 

FORMAT 

POSITIONS 

COMMENTS 

MAX.  VALUE 

GDATE 

8A1 

1-8 

Reference  date  for  positioning  special 
dates  specified.  (MM/DD/YY)  Must  be 
in  calendar  range. 

— 

MINCOD 

A2 

9-10 

Code  designating  type  of  format: 

If  blank,  card  is  type  "A" 

If  card  is  type  "B" 

JCODE (I) 

711 

11-17 

Each  position  corresponds  to  a  day  of 
the  week  (2=Monday) 

Coded  entries  specify  type  of  special 
date:  1  =  holiday,  2  =  blue  team  leave 
day,  3  =  gold  team  leave  day 

Notes: 

1.  If  card  is  type  "A"  (MINCOD  is  blank): 

a.  GDATE  must  be  a  Sunday  and  is  first  day  of  week  in  which  designated 
special  date(s)  fall. 

b.  JCODE  array  elements  which  are  not  blank  are  special  dates.  Correspond¬ 
ing  elements  of  calendar  array  are  loaded  with  holiday  or  leave  codes 

as  specified.  Other  days  of  that  week  are  set  blank,  replacing  values 
set  by  previously  read  card  for  same  week,  if  any. 

2.  If  card  is  type  "B"  (MINCOD  is  '--'): 

a.  GDATE  is  the  date  of  one  specific  holiday  (12/25/80,  for  example). 

b.  Day  of  the  week  need  not  be  determined. 

c.  Only  one  date  may  be  specified  per  card. 

d.  Code  to  be  entered  in  calendar  must  be  specified  in  JCODE(l)  position  11. 

e.  Other  days  of  that  week  are  unaffected. 

3.  Actually,  dates  may  be  in  any  of  3  formats:  YY  Julian  day,  DD/MM/YY  or 
MM/DD/YY.  Program  converts  all  to  MM/DD/YY. 


Figure  A6:  Record  Format  for  Special  Date  Cards 


RECORD  TITLE:  SUBJECT  CARD 


UNIT:  U5 


FORMAT  STATEMENT  NO.:  550 


FIELD  NAME 

FORMAT 

POSITIONS 

CONTENTS 

MAX.  VALUE 

SUBNAM(J,I) 

8A1 

1-8 

Subject  name  or  I.D.  (anything) 

— 

ITEAM 

12 

11-12 

Leave  team  assignment 

1  -  Blue 

2  -  Gold 

If  ■  0,  will  be  randomly  assigned 

2 

SENTRY 

8A1 

15-22 

Entry  date  (MM/DD/YY) 

— 

SEXITS 

8A1 

25-32 

Exit  date  (MM/DD/YY) 

_ 

Note:  See  Figure  A6  note  on  date  formats 


Figure  A7:  Record  Format  for  Subject  Cards 
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RECORD  TITLES  MILESTONE  TEST  CARL  UNIT:  U5 


FORMAT  STATEMENT  NO.:  705 


FIELD  NAME 

FORMAT 

POSITIONS 

CONTENTS 

MAX.  VALUE 

J 

15 

1-5 

Milestone  Number  (1,  2,  3,...) 

20 

MILK 

15 

6-10 

Test  Number  (6,  12,  18...) 

(A  "Backpointer"  not  used  by  program) 

— 

LLS(J) 

15 

11-15 

Number  of  items  in  this  list  of 
prerequisites 

10 

LINK (J, I) 

1015 

16-65 

List  of  prerequisite  tests 

120 

Figure  A8:  Record  Format  for  Milestone  Cards 
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RECORD  TITLE:  LABORATORY  SETUP  CARD 


UNIT:  U5 


FORMAT  STATEMENT  NO.:  760 


FIELD  NAME  FORMAT  POSITIONS 


CONTENTS 


MAX. 


LABSET(K)  1015  1-50  Type  of  test  each  lab  is  set  up  for,  one 

entry  per  lab.  (Values  are  normally 
positive;  user  may  set  any  negative  to 
suspend  for  that  lab  the  rule  which 
prohibits  changing  tests  except  in 
first  period  of  day  or  first  period  of 
second  block.) 


Figure  A9:  Record  Format  for  Laboratory  Setup  Card 


VALUE 
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RECORD  TITLE:  LABORATORY  DUAL-TRACK  DESIGNATOR  CARD 


UNIT:  U5 


FORMAT  STATEMENT  NO.:  760 


FIELD  NAME  FORMAT  POSITIONS  CONTENTS  MAX 


LABKEY(K)  1015  1-50  Lab.  number  of  first  track  of  a  dual-track 

pair.  This  entry  is  placed  in  the  array 
element  corresponding  to  the  second  track 
of  the  dual-track  pair,  (e.g.,  if  labs 
1  and  2  are  a  dual- track  pair,  enter  a 
1  in  LABKEY (2)  to  show  that  lab  2  is  the 
second  track  of  a  pair  of  which  lab  1  is 
the  first. 


Figure  A10:  Record  Format  for  Laboratory  Dual-Track  Card 


VALUE 

10 
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RECORD  TITLE:  TEST  CARD 


UNIT:  U5 


FORMAT  STATEMENT  NO.:  805 


FIELD  NAME 

FORMAT 

POSITIONS 

CONTENTS 

MAX.  VALUE 

J 

15 

1-5 

Test  number  (must  be  from  a  continuous 
sequence  of  Integers) 

120 

MTYPES(J) 

15 

6-10 

Test  type  code  (1  =  individual, 

2  =  small  group,  3  =  group) 

3 

MAXGRP(J) 

15 

11-15 

Max.  number  of  subjects  accommodated 
(Enter  101  if  whole  group) 

100 

MINGRP(J) 

15 

16-20 

Min.  No.  of  subjects  accommodated 

— 

MADMIN(J) 

15 

21-25 

No.  of  administrations  required 

(Defaults  to  'NADMIN'  on  control  card) 

— 

MILEST(J) 

15 

26-30 

Pointer  to  milestone  list 

20 

(Blank  if  test  Is  not  a  milestone, 
else  specify  which  list) 


KSTART 

15 

31-35 

Week  when  test  is  to  start 

(Blank  if  test  may  start  immediately) 

208 

KSTOPT 

15 

36-40 

Week  in  which  test  must  stop 
(Blank  if  test  has  no  cutoff) 

208 

NS TART 

8A1 

42-50 

Date  test  may  start  (MM/DD/YY) 

— 

NSTOPT 

8A1 

52-60 

Date  test  must  stop  (MM/DD/YY) 

— 

Figure  All:  Record  Format  for  Test  Cards 
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string  manipulation  routines  like  CHMOVE  anc’  the  IBM  absolute  value 
function  IABS,  may  have  UNIVAC  equivalents.  The  use  of  FILL  as  a  fast 
means  of  initializing  arrays  can  be  replaced  by  conventional  DO- loops. 

Extensive  use  is  made  in  SCHEDULER  of  two  Julian  date  conversion 
routines  DATEJ  and  JDAY.  It  may  be  possible  to  find  equivalent  UNIVAC 
routines,  but  their  elimination  would  have  a  serious  impact  on  program 
operation.  While  Julian  routines  would  not  be  necessary  if  scheduling 
were  done  strictly  with  respect  to  workdays,  eliminating  the  calendar 
feature  would  require  extensive  reprogramming.  The  source  code  for  these 
two  routines  is  available,  but  unfortunately  they  in  turn  call  other  local 
routines,  some  of  which  are  written  in  IBM  assembler  language,  thus  pre¬ 
senting  further  conversion  problems. 

The  percentage  completion  graphs  described  in  Section  II. A.  of  this 
report  were  produced  by  a  separate  plotting  program  which  processes  the 
X-Y  data  output  by  SCHEDULER  to  units  U37,  and  the  legend  information  in 
unit  U47.  This  program,  called  GRAPHAG,  converts  the  X-Y  pair  data  to  a 
file  of  pen  codes  which  can  be  used  by  AGILE  terminal  equipment  in  an  X-Y 
plotting  mode  to  produce  the  desired  plots  of  percentage  completion  as  a 
function  of  time.  Similar  UNIVAC  routines  may  exist  which  can  produce 
plots  from  a  set  of  X-Y  pairs,  perhaps  on  a  line  printer. 

C.  PROGRAM  RUN  TIME 

Typical  run  times  (on  an  IBM  370  computer  with  3033  CPU  using  MVT) 
for  nineteen  tests,  fourteen  subjects,  four  labs  and  ten  periods  per  day 
are: 


-47- 


Administrations 


Time  (seconds) 


15  23 

3  8 

1  7 

These  run  times  include  compilation  and  system  overhead  time  charges  as 
well  as  some  fixed  time  usage  involved  in  initialization  and  windup  within 
SCHEDULER. 


APPENDIX  II:  FLOW  CHARTS 


The  following  pages  present  a  system  flow  chart  designed  to  show  the 
broad  general  logic  of  the  SCHEDULER  program. 
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